FIG. 1 is a schematic illustration of a packet-based network such as the Internet 100, comprising a plurality of interconnected elements such as those labelled 102, 104 and 106. Each network element is connected to the rest of the Internet 100, and is configured to communicate data with other such elements over the Internet by transmitting and receiving data in the form of Internet Protocol (IP) packets. Each element also has an associated IP address locating it within the Internet. The elements shown explicitly in FIG. 1 are: a plurality of end-user terminals 102(A) to 102(E) such as desktop or laptop PCs; servers 104 and 104′ of Internet-based communication systems; and a gateway 106 to another type of network such as a traditional Public-Switched Telephone Network (PSTN) or other circuit switched network. However, it will of course be appreciated that many more elements make up the Internet than those explicitly shown. This is represented schematically in FIG. 1 by a communications cloud 108 which will include many other end-user terminals, servers and gateways, as well as routers of Internet service providers (ISPs) and Internet backbone routers.
Packet-based networks such as the Internet can be used to implement a number of different types of communication between end-users, such as voice-over-IP (VoIP) calls, video-over-IP calls, instant messaging (IM) chat sessions, and file transfer. To achieve this, each of a plurality of end-users installs and executes a client application on their respective terminal 102. The client applications together with any required functionality of servers 104 or 104′ form a communication system running over the Internet. Further, by communicating via a gateway 106, the system may also allow communication with other types of network such as PSTN network in order to call a conventional fixed land-line.
For example, voice-over-IP (VoIP) calls are beneficial to end-users because they are typically of significantly lower cost than fixed line or cellular mobile calls, often even free when from one VoIP client to another (rather than via a gateway 106 to another network). The cost savings may be particularly significant in the case of international or long-distance calls, since when communicating over the Internet using IP then the cost need not be dependent on distance. Similar comments may apply to video-over-IP calls.
In such communication systems, there are typically two pieces of information associated with each potential destination of a call: a user identifier (ID) which identifies the end-user, and an address which locates that user's terminal 102 within the network, in this case an IP address. That is, the user ID identifies a person whilst the address locates a terminal. Users will typically know each other's user IDs but not their address, since the user ID is typically a memorable name whereas the IP address is a long and cumbersome number. The user ID may often be referred to as the username. Further, IP addresses can sometimes change, either because they are dynamically allocated and/or because the users do not always use the same terminals, and therefore the IP address is not a reliable way for a user to indicate the intended destination of a call. For these reasons, users use each other's usernames to identify who to call. However, the IP address is the information required by the client application in order to locate the actual terminal 102 with which to establish the call. Therefore the communication system needs some means of mapping usernames to IP addresses in order to establish a call. The process of doing so is referred to as call set-up.
A similar process may apply to setting up a chat session or file transfer, and more generally the phrases “establishing a connection” or “connection set-up” may be used to cover any communication types such as voice or video calls, chat or file transfer. However, by way of example, the following will be described in terms of setting up a call.
Some Internet-based communication systems are managed by an operator, in that they rely on one or more centralised, operator-run servers 104 for call set-up. In that case, when an end-user (the caller) wishes to establish a call with another (the callee), then the caller must contact a server 104 run by the system operator to obtain the callee's IP address.
Referring to FIG. 1, consider for example that a user of a first terminal 102(A) wishes to call a user of a second terminal 102(B) using an operator managed system, with each user terminal 102(A) and 102(B) running a suitable client application. For the sake of example, the users are called “Jeremy” and “James” respectively. Jeremy indicates that he wishes to call James by specifying James' username to the client application running in his own terminal 102(A). To request the call set-up, the client application then supplies James' username from the first terminal 102(A) to the server 104. The server 104 maintains a list which maps usernames to corresponding IP addresses. Before responding to the request, the server 104 checks that Jeremy is authorised to access the list (e.g. by checking a password supplied with the request or with an earlier logon to the server 104). On condition that Jeremy is authorised, the server 104 then uses James' username to look up a corresponding IP address for the second terminal 102(B) and responds to the request by returning that IP address to the first terminal 102(A). The client application running on the first terminal 102(A) then uses the IP address to contact the second terminal 102(B) and thus establish a call therebetween, via whatever ISP and backbone routers are required.
In contrast to these operator managed systems, another type of Internet-based communication system is known as a “peer-to-peer” (P2P) network. A peer-to-peer network is an example of an overlay network, which is a network implemented at the application layer and said to be run “on top of” a lower level network such as the Internet. The idea behind peer-to-peer (P2P) networks is to devolve responsibility away from centralised operator servers and into the end-users' own terminals. In the least, it is a characterising feature of a P2P communication network that responsibility for call set-up (or more generally connection set-up) is devolved to end-user terminals like those labelled 102 in FIG. 1. Each user terminal runs a P2P client application, and each such terminal forms a node of the P2P network. P2P call set-up works by distributing a list mapping usernames to IP addresses amongst a subset of the end-user nodes, termed herein “super-nodes”. The list maps the usernames of all online or recently online users to the relevant IP addresses. Each super-node acts as an IP address look-up point for a group of other local nodes, and its respective list contains the usernames and IP addresses of the nodes in that local group. The group need not necessarily be local in terms of geographical location, but rather in terms of how directly connected the nodes are to the super-node (which may be related to geographical location). Each client will monitor certain factors of its respective terminal 102 such as constancy of IP address and up-time to determine whether it should become a super-node. If so, the IP address of the super-node is advertised to the client applications running on other local nodes, and the super-node gathers the IP addresses and usernames of those local nodes for its list. Then, instead of contacting a server 104, a caller will contact a local super-node to look up the IP address of the callee. If the local super-node does not have the required IP address in its list because it is not local to the callee, then it may in turn contact another super-node which is local to the callee to determine the required address. In this way, the list mapping usernames to IP addresses is distributed amongst end-user nodes and no server is required for call set-up.
Consider again the example where Jeremy wishes to call James, but this time using a P2P network. For example, say another user terminal 102(E) happens to be the local super-node of the first terminal 102(A). Instead of contacting a server 104 to establish a call, the client of the first node 102(A) contacts the client application running on the super-node terminal 102(E). The client on the first node 102(A) then supplies James' username to the super-node 102(E), and the client on the super-node 102(E) checks whether it has the IP address of the second node 102(B). If the second node 102(B) is also a local node of the super-node 102(E), then the super-node 102(E) will have the required IP address and will return it to the first node 102(A). If on the other hand the second node 102(B) is not a local node of the super-node 102(E), then the client on the super-node 102(E) must refer to another super-node (not shown). In that case, the client on the other super-node returns the required IP address to the first nodes's local super-node 102(E), and in turn the client on that super-node 102(E) returns the IP address to the first node 102(A). The client on the first node 102(A) can then use this IP address to contact the second node 102(B) and thus establish a call therebetween, again via whatever ISP and backbone routers are required. Note that the users of the super-node terminals (e.g. Adam) are themselves end-users of the P2P network but are not personally involved in the call or its set-up in any way. That is to say, they are not participants of the call. Rather, their client applications handle the address look-up automatically.
More details of call set-up in an exemplary P2P system can be found in WO 2005/008524.
In addition to call set-up, a supplier of the P2P client application may choose to provide some additional, secondary features which in contrast to call set-up may involve a server 104′. One such function is the distribution of authentication certificates. Because call set-up is not performed via an operator server 104, then a server cannot be used to check whether a callee is in fact authorised to contact any given caller. Instead therefore, when a user first registers with the P2P system then their client application is provided with a digital certificate from a different server 104′, termed herein a P2P server. This is preferably a one-time initial registration. Once the client software has been provided with the certificate, then calls or other connections can subsequently be set up and routed between users of the P2P system without the further use of a server. In particular, the users can establish their own communication routes through the P2P system based on the exchange of one or more these digital certificates (or user identity certificates, “UIC”), which enable access to the P2P system. The exchange of the digital certificates between users provides proof of the users' identities and that they are suitably authenticated in the P2P system. Therefore, the presentation of digital certificates provides trust in the identity of the user.
Further details on the use of digital certificates for authentication in an exemplary P2P system can be found in WO 2005/009019.
The P2P server 104′ may also be used to provide some other secondary features in relation to a P2P network, such as to host “contact lists” (lists of users' favourite contacts), “avatar” images (chosen by the users to represent themselves graphically to others of the P2P network) and/or presence information (user-defined status information such as their location, mood and whether the user is available for communication).
Nonetheless, the primary function of call or connection set-up is still handled in a distributed fashion by end-user nodes, not by a server. Further, after initial registration, authentication preferably proceeds between end-user nodes without any further involvement of a server.
Another point of note in some P2P networks is that it may be necessary to route communications via relay nodes in order to traverse firewalls. Firewalls may only trust a limited number of nodes of the P2P network, and if the caller and callee's firewalls do not trust each other's nodes then it may be necessary to for their client applications to relay traffic via one or more other nodes of the P2P network. For example, if Jeremy wishes to call James but the firewall running on Jeremy's terminal 102(A) does not trust James' terminal 102(B) and vice versa, then they cannot communicate directly with one another even after Jeremy has retrieved James' IP address from the relevant super-node. In that case, the clients running on the first and second nodes may transmit and receive data traffic via another node such as 102(C) or 102(D) which is trusted by both Jeremy and James' firewalls. This traffic could comprise for example audio streams, video streams, file transfer streams and/or chat messages. The users of the relaying nodes (e.g. John or Harriet) are themselves end-users of the P2P network but are not personally involved in the call or the relaying process in any way, i.e. are not participants. Instead, the respective client application of the relay node handles the relaying automatically (the non-participating user will have previously agreed to such situations when installing the client application, and may themselves benefit from reciprocal situations in future). The relay node is only a relay and does not consume the stream, i.e. does not display or playback the stream in the case of video or audio streams nor store the file in the case of a file transfer stream.
The advantage of P2P networks is that they allow end-users to establish communication connections over the Internet without requiring substantial management from a network operator. Instead, they only require a supplier of a suitable client application, who may also provide certain other secondary functions from a P2P sever. Nonetheless, the inventors believe there is still potential to extend the scope of P2P networks or indeed other networks of end-user nodes. Particularly, such networks are not well suited for disseminating content such as voice, video or file transfers to a group of multiple end-user nodes. Typically they operate by establishing multiple one-to-one connections directly between the source user's node and each of the other end-user nodes in the group. This gives rise to significant resource demands at the source node, in terms of available bandwidth and processing. It would be desirable to overhaul the infrastructure of a P2P network or other network of end-user nodes in order to better provide multi-party dissemination of content.